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REMARKS 

I Summary of the Amendments 

The present patent application still comprises fifty (50) claims, numbered 1 to 30, 35, 38 to 
41, 50 to 55 and 59 to 67. 

Claims 1 and 65 have been amended. Claims 31 to 34, 36, 37, 42 to 49 and 56 to 58 have 
been previously cancelled. 

Support for amendments made can be found throughout the specification and drawings as 
originally filed. No new matter has been added to the present patent application by the 
present amendment, 

II Rejection of Claims 1 to 30, 35, 50 to 55 and 59 to 67 under 35 USC 103 

On pages 2 to 31 of the Final Office Action, the Examiner rejected claims 1 to 30, 35, 50 to 
55 and 59 to 67 under 35 USC 103(a) as being unpatentable over U.S. Patent No. 6,577,634 
to Tsukakoshi et al. (hereinafter referred to as "Tsukakoshi") in view of U.S. Patent No. 
6,947,963 to Agarwal et al. (hereinafter referred to as "Agarwal"). 

As described below, the Applicants respectfiiUy submit that claims 1 to 30, 35, 50 to 55 and 
59 to 67, as amended, are in condition for allowance. 

Independent claims 1 , 23 and 65 

Excerpts of claims 1, 23 and 65 are presented below, with certain elements being 
emphasized: 

1. A router supporting multiple routing protocols, said router comprising: 

[...] 

c. a routing layer in communication with said interface layer, said routing layer 
including a plurality of routing protocol computing entities, each routing 
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protocol computing entity being associated with a set of at least one routing 
protocol and including: 

i. a CPU; and 

ii. a data storage medium in communication with said CPU and storing 
program data for execution by said CPU to cause said routing 
protocol computing entity to eflfect management of one or more 
peering sessions with remote routing devices according to the at 
least one routing protocol in the set associated with said routing 
protocol computing entity, said management of one or more peering 
sessions comprising maintaining in said data storage medium one or 
more route databases including routing data; 

wherein the set of at least one routing protocol associated with a first one of 
said routing protocol computing entities is different from the set of at least 
one routing protocol associated with a second one of said routing protocol 
computing entities; 

wherein the one or more route databases maintained in the data storage 
medium of said first one of said routing protocol computing entities 
contain information on at least one route for which there is no 
information in the one or more route databases maintained in the data 
storage medium of said second one of said routing protocol computing 
entities; 

[...] 

23. A router, comprising: 

[•••] 

c. a routing layer in communication with said interface layer, said routing layer 
including a plurality of routing protocol computing entities, each routing 
protocol computing entity being associated with a routing protocol and 
including: 

i. a CPU; and 

ii. a data storage medium in communication with said CPU and storing 
program data for execution by said CPU to cause said routing 
protocol computing entity to effect management of one or more 
peering sessions with remote routing devices according to the 
routing protocol associated with said routing protocol computing 
entity, said management of one or more peering sessions comprising 
maintaining in said data storage medium one or more route 
databases; 

wherein the routing protocol associated with a first one of said routing 
protocol computing entities is the same as the routing protocol associated 
with a second one of said routing protocol computing entities; 
wherein the one or more route databases maintained in the data storage 
medium of said first one of said routing protocol computing entities 
contain information on at least one route for which there is no 
information in the one or more route databases maintained in the data 
storage medium of said second one of said routing protocol computing 
entities. 

65. A router supporting multiple routing protocols, said router comprising: 

[...] 
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c. a routing layer in communication with said interface layer, said routing layer 
including a plurality of routing protocol computing entities, each routing 
protocol computing entity being associated with a set of at least one routing 
protocol and including: 

i. a CPU; and 

ii, a data storage medium in communication with said CPU and storing 
program data for execution by said CPU to cause said routing 
protocol computing entity to effect management of one or more 
peering sessions with remote routing devices according to the at 
least one routing protocol in the set associated with said routing 
protocol computing entity, said management of one or more peering 
sessions comprising maintaining in said data storage medium one or 
more route databases including routing data; 

wherein the set of at least one routing protocol associated with a first one of 
said routing protocol computing entities is different from the set of at least 
one routing protocol associated with a second one of said routing protocol 
computing entities; 

wherein the one or more route databases maintained in the data storage 
medium of said first one of said routing protocol computing entities 
contain information on at least one route for which there is no 
information in the one or more route databases maintained in the data 
storage medium of said second one of said routing protocol computing 
entities; 

[...] 



The Applicants respectfully submit that Tsukakoshi and Agarwal, whether taken separately or 
in combination, do not teach or suggest a router as claimed in each of claims 1, 23 and 65, 
and, in particular, do not teach or suggest the above-emphasized elements of these claims. 

Specifically, neither Tsukakoshi nor Agarwal teaches or suggests a plurality of routing 
protocol computing entities each associated with a routing protocol and each including a CPU 
and a data storage medium, where the one or more route databases maintained in the data 
storage mediimi of a first routing protocol computing entity contain information on at least 
one route for which there is no iirformation in the one or more route databases maintained in 
the data storage medium of a second routing protocol computing entity. 
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As conceded by the Examiner on page 9 of the Final Office Action in connection with claim 
23, Tsukakoshi neither teaches nor suggests this element, which is now claimed in each of 
claims 1, 23 and 65*. 

To address this deficiency of Tsukakoshi, the Examiner applies Agarwal and contends that it 
discloses the claimed element missing from Tsukakoshi. In an attempt to support this 
contention, the Examiner refers to Figure 2 and column 8, lines 1 to 15 as well as Figure 3 of 
Agarwal and states that "for instance Route Data B is not contained in Control Card 
LIA/RPA". 

With respect, the Examiner's contention is incorrect as Agarwal fails to disclose or suggest 
the above-emphasized claim element, which the Examiner already conceded is absent from 
Tsukakoshi. 

Specifically, Agarwal describes a router including control cards with processors, where each 
processor runs zero or more routing protocols of a complement of routing protocols and 
receives a full complement of routing data generated by the complement of routing protocols 
(column 3, line 61 to column 4, line 7; and column 4, lines 49 to 60). This is ample clear fi-om 
Agarwal as a whole and in fact fi-om the very passage referred to by the Examiner where 
Agarwal, in describing Figure 2, states that "the LI [processor] for each control card requires 
route data from the full complement of routins protocols '^ (emphasis added - column 8, lines 
10 to 13). Not only does this not support the Examiner's contention regarding what Agarwal 
allegedly discloses, but this totally contradicts the Examiner's contention. 

More specifically, a central and essential aspect of Agarwal' s router is that the routing 
database maintained by each processor is synchronized to contain route data from the full 

^ Indeed, as shown on pages 26 and 27 of the response filed on September 13, 2006, Tsukakoshi's clustered 
router 1 1 is designed to ensure that all of its route calculation units 20 have the same routing information in their 
memory 42. In other words, there is duplication of network information 16 across all the route calculation units 
20. This entails that the routing information stored in the memory 42 in all of Tsukakoshi's route calculation 
units 20 contain information on identical sets of routes. Therefore, as conceded by the Examiner, Tsukakoshi 
fails to teach or suggest the claimed feature whereby the one or more route databases maintained in the data 
storage medium of a first routing protocol computing entity contain information on at least one route for which 
there is no information in the one or more route databases maintained in the data storage medium of a second 
routing protocol computing entity. 
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complement of routing protocols running on all processors (column 2, lines 46 to 49; column 
3, lines 1 1 to 14, 19, 20 and 28 to 31; column 4, lines 3 to 7, 55 to 60; column 7, lines 23 to 
35; and column 8, line 66 to column 9, line 3). This entails that the routing databases in all of 
Agarwal's control cards contain information on identical sets of routes. Therefore, Agarwal 
clearly fails to teach or suggest the claimed scenario where the one or more route databases 
maintained in the data storage medium of a first routing protocol computing entity contain 
information on at least one route for which there is no information in the one or more route 
databases maintained in the data storage medium of a second routing protocol computing 
entity. 

Regarding the Examiner's reference to Figure 3 of Agarwal, the Examiner will note that, 
while Figure 3 does not show arrows indicating transfer of Route Data B from either 
LIB/RPB or LIB'/RPB (acting as servers in Agarwal's terminology) to LIA'/RPA (acting as 
a client in Agarwal's terminology), Agarwal's description of this figure states that an LI 
processor "may have both client and server functionality concurrently" and that, '"^[fjor the 
sake of clarity^ LI A' and LIB are not shown as clients, but as servers only" (emphasis added 
- column 8, lines 33 to 35). In other words, Agarwal's Figure 3 does not show transfer of 
route data between all LI processors shown in that figure simply to facilitate description of 
part of the functionality of these processors. This drav^ng simplification in no way changes 
the fact that a central and essential aspect of Agarwal's router is that the routing database 
maintained by each processor is synchronized to contain route data from the full complement 
of routing protocols running on all processors, and thus that the routing databases in all of 
Agarwal's control cards contain information on identical sets of routes. 

Accordingly, Agarwal (like Tsukakoshi) fails to teach or suggest a plurality of routing 
protocol computing entities each associated with a routing protocol and each including a CPU 
and a data storage medium, where the one or more route databases maintained in the data 
storage medium of a first routing protocol computing entity contain information on at least 
one route for which there is no information in the one or more route databases maintained in 
the data storage medium of a second routing protocol computing entity. 
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In light of the above, it is respectfully submitted that at least one element of each of claims 1, 
23 and 65, is neither taught nor suggested by Tsukakoshi and Agarwal, whether taken 
separately or in combination. Therefore, the Applicants respectfully submit that at least one 
criterion required for establishing a prima facie case of obviousness in accordance with 
MPEP 706.02(j)^ is not satisfied. The Examiner is thus respectfully requested to withdraw the 
rejection of claims 1, 23 and 65, which are believed to be in condition for allowance. 



Dependent claims 2 to 22, 24 to 30. 50 to 55. 59 to 64. 66 and 67 



Each of claims 2 to 22, 24 to 30, 50 to 55, 59 to 64, 66 and 67 depends on one of claims 1, 23 
and 65 and thus incorporates by reference all the elements of that base claim. Hence, for the 
same reasons as those set forth above in respect of claims 1, 23 and 65, the Applicants 
respectfully submit that claims 2 to 22, 24 to 30, 50 to 55, 59 to 64, 66 and 67 are in 
condition for allowance and respectfully request the Examiner to withdraw the rejections of 
these claims. 



Independent claim 35 



Claim 35 is reproduced below with certain elements being emphasized: 



A router, comprising: 

a. an interface layer including a plurality of I/O controllers, each I/O 
controller implementing an I/O port; 

b. a switching layer in communication with said interface layer for selectively 
establishing signal pathways between said I/O ports; 

c. a routing layer in communication with said interface layer, said routing layer 
comprising a routing protocol computing entity capable of managing at least 
one peering session with a remote routing device, the peering session 
including the exchange of messages with the remote routing device through 
one of the I/O controllers, the peering session being comprised of a plurality 
of tasks; 

d. the one I/O controller implementing a peering session assist module, 



^ For the Examiner to establish a prima facie case of obviousness, three criteria must be considered: (1) there 
must be some suggestion or motivation, either in the references themselves or in the knowledge generally 
available to one of ordinary skill in the art, to modify the reference or to combine the reference teachings, (2) 
there must be a reasonable expectation of success, and (3) the prior art references must teach or suggest all of 
the claim limitations. MPEP §§ 706.02G), 2142 (8th ed.). 
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e. said peering session assist module being capable of performing some of 
the tasks of the peering session autonomously from said routing 
protocol computing entity of said routing layer; 

f. said routing layer being capable of performing tasks of the peering session 
other than the tasks performed by the peering session assist module; 

wherein the tasks performed by the peering session assist module autonomously 
from said routing protocol computing entity include authenticating, without 
intervention of said routing protocol computing entity, messages received from 
the remote routing device. 

The Applicants respectfully submit that Tsukakoshi and Agarwal, whether taken separately or 
in combination, do not teach or suggest the above-emphasized elements of claim 35. 

Specifically, neither Tsukakoshi nor Agaiwal teaches or suggests an I/O controller of an 
interface layer of a router that implements a peering session assist module capable of 
authenticating , without intervention of a routing protocol computing entity of a routing layer 
of the router, messages received from a remote routing device during a peering session 
between the router and the remote routing device . 

As conceded by the Examiner on page 29 of the Final Office Action, Tsukakoshi does not 
teach or suggest these elements of claim 35. 

To address this deficiency of Tsukakoshi, the Examiner applies Agarwal and contends that: 
(1) Agarwal discloses a peering session assist module constituted by Agarwal' s Route Table 
Manager and residing both on Agarwal's Line Cards and Control Cards; (2) "autonomous 
peering sessions are readily established [...] between Controller cards and [...] between Line 
Cards"; and (3) "at the I/O level which is at the Line card registration and authentication of 
registered members occurs independent of the routing layer". In an attempt to support this 
contention, the Examiner refers to Agarwal 's Figures 1 and 4 and column 6, lines 10 to 30; 
Figures 3 and 6 and column 4, lines 14 to 30; and Figure 6 and column 10, lines 20 to 35. 

With respect, the Examiner's contention is incorrect as Agarwal fails to disclose or suggest 
the above-emphasized elements of claim 35, which the Examiner already conceded are absent 
from Tsukakoshi. 



25 



Application No. 09/915,332 
Submission to accompany RCE 



Patent 

Attorney Docket No. 86655-5 
(formerly 86177-11) 



To begin with, the Examiner should be aware that "peering" has a well-estabHshed meaning 
in the art and refers to communication of route information between routers through routing 
protocols. In fact, as mentioned on page 7, lines 6 to 8 of the present application as originally 
filed, "peering session'' is used in a broad sense with the intent to encompass the 
communication of route information from one router to another router , irrespective of the 
routing protocol used. Furthermore, claim 35 itself refers to a peering session with a remote 
routing device , the peering session including the exchange of messages with the remote 
routing device through one of the I/O controllers of the claimed router. It should thus be clear 
to the Examiner that "peering" refers to communication of route information between routers . 

Now, the interaction between Agarwal's control cards and between Agarwal's line cards 
referred to by the Examiner relates to establishing communication between entities within 
Agarwal's router as client-server relationships. This is clearly not "peering" as it is not 
communication of route information between routers . On that basis alone, it is ample clear 
that the Examiner's contention is incorrect as the passages of Agarwal referred to by the 
Examiner do not at all relate to "peering". 

Since the passages of Agarwal referred to by the Examiner do not relate to "peering" in the 
first place, it goes without saying that they cannot possibly teach or suggest authentication of 
messages received from a remote router during a peering session . 

Accordingly, Agarwal (like Tsukakoshi) fails to teach or suggest an I/O controller of an 
interface layer of a router that implements a peering session assist module capable of 
authenticating , without intervention of a routing protocol computing entity of a routing layer 



^ Notwithstanding this, the Examiner will note that these passages do not relate to authentication . Specifically, 
the Examiner will appreciate that "authentication", both in the art and in ordinary parlance, refers to verifying 
that something is what it claims to be. A server verifying that a proposed client is what it says it is can in no way 
be construed as the same as checking whether the server itself has the capability to accept a new client. The 
Examiner's allegation that Agarwal's column 10, lines 20 to 35 teaches "authentication" is thus contradicted by 
the inmiediately preceding lines (column 10, lines 17 to 19), which clearly describe that the example of denial of 
establishing a relationship is related to the capacity of the server in the proposed relationship. Therefore, not 
only are the passages of Agarwal referred to by the Examiner irrelevant to authentication of messages received 
from a remote router during a peering session, but these passages are irrelevant to the general concept of 
authentication. 
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of the router, messages received from a remote routing device during a peering session 
between the router and the remote routing device . 

In light of the above, it is respectfully submitted that at least one element of claim 35 is 
neither taught nor suggested by Tsukakoshi and Agarwal, whether taken separately or in 
combination. Therefore, the Applicants respectfully submit that at least one criterion required 
for establishing a prima facie case of obviousness in accordance with MPEP 706.02(j) is not 
satisfied. The Examiner is thus respectfully requested to withdraw the rejection of claim 35, 
which is believed to be in condition for allowance. 

Ill Rejection of Claims 38 and 41 under 35 USC 103 

On pages 31 to 36 of the Final Office Action, the Examiner rejected claims 38 and 41 under 
35 USC 103(a) as being unpatentable over U.S. Patent No. 6,577,634 to Tsukakoshi et al 
(hereinafter referred to as "Tsukakoshi") in view of U.S. Patent No. 6,049,524 to Fukushima 
et al (hereinafter referred to as "Fukushima") and U.S. Patent 7,003,582 to Basso et al 
(hereinafter referred to as "Basso"). 

As described below, the Applicants respectfully traverse this rejection and submit that claims 
38 and 41 are in condition for allowance. 

Independent claim 38 

Claim 38 is reproduced below with certain elements being emphasized: 
A router, comprising: 

a. an interface layer including a plurality of I/O controllers, each I/O controller 
implementing an I/O port; 

b. a switching layer in communication with said interface layer for selectively 
establishing signal pathways between said I/O ports; 

c. a routing layer in communication with said interface layer; 

d. each I/O controller implementing an LSA entity, said LSA entity including 
an LS database, said LSA entity being responsive to an LSA message from 
a remote routing device including LS information to: 

i. update said LS database; and 

ii. forward the LS information to said routing layer. 
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It is respectfully submitted that Tsukakoshi, Fukushima and Basso, whether taken separately 
or in combination, do not teach or suggest an I/O controller of an interface layer of a router 
that implements an LSA entity , where the LSA entity includes an LS database and is 
responsive to an LSA message from a remote routing device including LS information to: 
update the LS database : and 

forward the LS information to a routing layer of the router. 

Firstly, as conceded by the Examiner on page 32 of the Final Office Action, Tsukakoshi fails 
to disclose these elements of claim 38. 

To address this deficiency of Tsukakoshi, the Examiner applies Fukushima. However, as 
discussed below, Fukushima also fails to teach or suggest the above-mentioned elements of 
claim 38 that are missing from Tsukakoshi, and thus would not lead one ordinarily skilled in 
the art any closer to the router claimed in claim 38. Specifically, the Examiner's attention is 
directed to the following three (3) points: 

1 . While Fukushima indeed describes an LS database 22, this LS database 22 is clearly 
maintained in Fukushima's route calculation unit 11, i.e., in Fukushima's routing 
layer . Therefore, it is abundantly clear that the LS database 22 is not maintained in 
Fukushima's forwarding process units 13, i.e., it is not maintained in Fukushima's 
interface layer (column 5, lines 60 to 67; column 6, lines 1 to 4; and Figure 2). 

2. The Examiner appears to contend, on page 33 of the Final Office Action, that the 
routing table 19 in each of Fukushima's forwarding process units 13 corresponds to a 
link state (LS) database. The Examiner's contention is incorrect for at least the 
following two reasons. 

Firstly, a link state database is an industry standard term that is distinct from a routing 
table, which is another industry standard term. This is evidenced by Fukushima itself 
that clearly differentiates between its link state database 22 and its routing table 19 
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(column 5, line 67 to column 6, line 3; column 6, lines 7 to 11; and Figure 2). As 
further evidence that a link state database is not a routing table (and vice versa), 
Fukushima itself explicitly states that "[its] routing table 19 is created from [its] link- 
state database 22" (emphasis added - column 6, lines 50 and 51). 

Secondly, the content of a link state database is completely different from the content 
of a routing table. Specifically, a routing table does not contain information on the 
state of links, it contains information on routes. While a change in the state of a link 
can cause routes to be added or removed, the routing table only contains information 
on the resulting routes, not information on the state of the link that caused the change. 
Link states are not routes, and routes are not link states. This difference in content 
between a link state database and a routing table is clearly evidenced by Fukushima 
itself, which describes and shows in Figures 4 and 5 that the content of its link state 
database 22 is completely different from the content of its routing table 19 (column 4, 
lines 55 to 58 and column 6, lines 27 to 60). 

The Examiner's apparent contention that the routing table 19 in each of Fukushima' s 
forwarding process units 13 corresponds to a link state (LS) database is therefore 
incorrect. 

3. The Examiner contends on pages 33 and 38 that it would have been "obvious to one 
ordinarily skilled in the art to move the Link State Database from the routing layer to 
the Forwarding (i.e. I/O Controller) layer by implementing it as a distributed database 
in order to prevent a single point of failure". 

With respect, this contention is untenable since Fukushima' s router already has 
backup databases in route calculation units of its routing layer and so there is already 
no single point of failure (column 7, lines 46 to 60)! 

Thus, contrary to the Examiner's contention, it would not have been obvious to one 
ordinarily skilled in the art to move the link state database from the routing layer to 
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the forwarding layer in order to prevent a single point of failure, as there would be no 
motivation to do so in view of Fukushima. 



For these reasons, it is apparent that Fukushima neither teaches nor suggests an I/O controller 
of a router's interface layer that implements an LSA entity including an LS database and 
having the updating and forwarding functionality claimed in claim 38. 

With respect to Basso, this reference also fails to teach or suggest the above-mentioned 
features of claim 38 that are missing from Tsukakoshi and Fukushima. Specifically, each NP 
processor 12 of Basso's system supports a number of interface ports 20 and maintains a 
forwarding table 18 (column 2, lines 8 to 11 and 36 to 42). Basso in no way teaches or 
suggests an I/O controller of a router's interface layer that implements an LSA entity 
including an LS database and having the updating and forwarding functionality claimed in 
claim 38. 



In light of the above, it is respectfully submitted that at least one element of claim 38 is 
neither taught nor suggested by Tsukakoshi, Fukushima and Basso, whether taken separately 
or in combination. Therefore, the Applicants respectfully submit that at least one criterion 
required for establishing a prima facie case of obviousness in accordance with MPEP 
706.02(j) is not satisfied. The Examiner is thus respectfully requested to withdraw the 
rejection of claim 38, which is believed to be in condition for allowance. 



Dependent claim 41 

Claim 41 depends on claim 38 and therefore incorporates by reference all the elements of 
claim 38. Hence, for the same reasons as those set forth above in respect of claim 38, the 
Applicants respectfiiUy submit that claim 41 is in condition for allowance and respectfiiUy 
request the Examiner to withdraw the rejection of this claim. 

IV Rejection of Claims 39 and 40 under 35 USC 103 
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On pages 36 and 37 of the Final Office Action, the Examiner rejected claims 39 and 40 under 
35 use 103(a) as being unpatentable over U.S. Patent No. 6,577,634 to Tsukakoshi et al 
(hereinafter referred to as "Tsukakoshi") in view of U.S. Patent No. 6,049,524 to Fukushima 
et al (hereinafter referred to as "Fukushima") and U.S. Patent 7,003,582 to Basso et al 
(hereinafter referred to as "Basso"), and in fiirther view of U.S. Patent No. 6,820,134 to Zinin 
et al (hereinafter referred to as "Zinin"). 

As described below, the Applicants respectfully traverse this rejection and submit that claims 
39 and 40 are in condition for allowance. 

Dependent claims 39 and 40 

Each of claims 39 and 40 depends on claim 38 and therefore incorporates by reference all the 
elements of claim 38. 

As already shown in respect of claim 38, Tsukakoshi, Fukushima and Basso, whether taken 
separately or in combination, do not teach or suggest an I/O controller of an interface layer of 
a router that implements an LSA entity , where the LSA entity includes an LS database and is 
responsive to an LSA message fi-om a remote routing device including LS information to: 
update the LS database ; and 

forward the LS information to a routing layer of the router. 

Fxirthermore, Zinin also fails to teach or suggest these elements of claim 38 (and thus of 
claims 39 and 40) that are missing ft-om Tsukakoshi, Fukushima and Basso. Specifically, 
while Zinin describes a link state database 220, this link state database 220 is clearly not 
maintained in any of Zinin's network interfaces 210A to 210D, i.e., in Zinin's interface layer 
(column 6, lines 31 to 34 and Figure 2). 

In light of the above, it is respectfiilly submitted that at least one element of each of claims 39 
and 40 (by virtue of their dependency on claim 38) is neither taught nor suggested by the 
cited references, whether taken separately or in combination. Therefore, the Applicants 
respectfiilly submit that at least one criterion required for establishing a prima facie case of 
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obviousness in accordance with MPEP 706.02(j) is not satisfied. The Examiner is thus 
respectfully requested to withdraw the rejection of claims 39 and 40, which are believed to be 
in condition for allowance. 
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CONCLUSION 



The Applicants are of the view that claims 1 to 30, 35, 38 to 41, 50 to 55 and 59 to 67 are in 
condition for allowance. Favorable reconsideration is requested. Early allowance of the 
present patent application is earnestly solicited. 

If the present patent application is not considered to be in full condition for allowance, for 
any reason, the Applicants respectfully request the constructive assistance and suggestions of 
the Examiner in drafting one or more acceptable claims pursuant to MPEP 707.07(j) or in 
making constructive suggestions pursuant to MPEP 706.03 so that the application can be 
placed in allowable condition as soon as possible and without the need for fiirther 
proceedings. 
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